Interrupt requests are mechanisms to notify a processor about an event (an interrupt triggering event) in an asynchronous way.
Sometimes a series of events could happen within a short period of time causing the processor to be bombarded with many interrupt requests in short period of time that could potentially lead to inefficient performance.
FIG. 1 illustrates the occurrence of three interrupt triggering events—represented by indications In1-In3 11-13. The indication about the occurrence of the first event In1 11 triggers (arrow 31) a generation of an interrupt request (the interrupt request signal 20 is de-asserted at time 21), that is followed by generating another interrupt request (in response to In 2 12—arrow 32 at time 22 causes the interrupt request signal 20 to maintain low till point in time 32). The indication about the occurrence of the third event In3 13 triggers (arrow 33) a generation of an interrupt request (the interrupt request signal 20 is de-asserted at time 24).
To overcome this, few implementations added the notion of “interrupt coalescing” or “interrupt moderation”.
Interrupt moderation includes delaying the generating of each interrupt request. Each interrupt request or a group of interrupt requests have an associated timer. At a moment an indication about an occurrence of an interrupt triggering event is received, the timer (associated with that interrupt triggering event) is loaded and start counting (either loaded a value and count down to zero, or start from zero and count up to a limit).
FIG. 2 illustrates the occurrence of three interrupt triggering events—represented by indications In1-In3 11-13. The indication about the occurrence of the first event In1 11 causes (arrow 43) a timer to count for n cycles thereby delaying the generation of a “merged” interrupt request after a delay 42 lapses from the reception of In 11. When the delay ends (arrow 51) a “merged” interrupt request 61 is generated (the interrupt request signal 60 is de-asserted).
Accordingly—each interrupt request is not asserted until the timer expires, and this will enable the potential accumulation of multiple interrupt triggering events that could have happened in time proximity, and only assert the interrupt request once after the timer expires.
To reduce the number of interrupt requests, many network interface controllers (NICs) use interrupt moderation. With interrupt moderation, the NIC will not generate an interrupt request immediately after it receives a packet (the reception of a packet is an interrupt triggering event). Instead, the NIC introduced a delay and waits for more packets to arrive, or for a time-out to expire, before generating an interrupt request. The NIC vendor specifies the maximum number of packets, time-out interval, or other interrupt moderation algorithm—but in any case each interrupt request is delayed.
The measured round-trip time for a packet is one of the most commonly used techniques to determine the network bandwidth between two endpoints. However, when interrupt moderation is enabled, receiving a packet does not generate an immediate interrupt request and therefore the perceived round-trip time for a particular packet becomes larger than the average time. To allow accurate measurement of round trip time for a packet, NDIS provides the ability to disable and enable interrupt moderation—thus either all interrupt requests are delayed or all interrupt requests are not delayed.
The downside of this implementation—once interrupt moderation is enabled, and the timer is used, it is perceived that the latency is high due to this coalescing impact latency sensitive applications
This caused many vendors not to implement interrupt moderation or give the option to disable it for latency sensitive applications.